I had a thought about this and I think I do not want to modify the Advice class. It's already quite complicated and I think that adding more properties to it is the wrong direction. In particular, it means you have to have the nullable line number available at construction time, which really complicates things. Instead, I propose that the report-generating task in the project (not buildHealth, to be clear) optionally* iterate over the advice and write out a new output with a new model that includes the advice and the line number. That new class might look like this:

*this should be opt-in, based on user preference.

public data class SarifAdvice( // name TBD
  advice: Advice,
  lineNumber: Int?,
)

And then we could emit a sorted set of SarifAdvice in json form to disk. That could then be further processed by projectHealth and buildHealth.

There are already examples in the project of configuring something in the root and having that value picked up safely in subprojects. If you need pointers, please let me know.

So you would want to generate yet another json next to the regular advice json just for an extra property and then consume that json in addition to the regular json? Sounds a pretty complicated thing to do.

Or did I miss the intention here?

So you would want to generate yet another json next to the regular advice json just for an extra property and then consume that json in addition to the regular json? Sounds a pretty complicated thing to do.

Or did I miss the intention here?

Yes, that's correct. And also that feature should be opt-in, based on user preference (as expressed in the reporting DSL).

In my opinion, this is actually easier than what you've spiked here. json is cheap.

Updated. now dependency filtering task will also emit final-sourced-advice.json after filtering. If this is okay, I can continue with the implementation of the per-project report.

There is also an issue of reporting configuration: reportingHandler is a singleton in the GlobalDslService, which means that, currently, projects cannot each set their own reporting configuration (changing it in one project would override the config in all of them). Are there any negative side effects if I make this not-singleton?

There is also an issue of reporting configuration: reportingHandler is a singleton in the GlobalDslService, which means that, currently, projects cannot each set their own reporting configuration (changing it in one project would override the config in all of them). Are there any negative side effects if I make this not-singleton?

I think it should remain a singleton. I don't see the benefit of allowing per-project variation here. Do you?

Yeah, then I should revert the reporting handler being accessible from project - it would only be configurable from the root project.

This is an unusual UX for the Gradle project, though. It is generally expected, that every project's configuration is only affecting that project, not anything else (especially after Isolated Projects). Configuration for root project affecting other project is a bit unexpected. But I guess DAGP has already set a precedent for this with bundles being set only on root, but applying everywhere.